Hash Collision
Different keys can legitimately map to the same bucket.
Separate chaining stores multiple entries in the same bucket.
Open addressing searches for another available slot.
High collision rates increase lookup cost.
A good hash function reduces collisions but cannot eliminate them completely.
If you insert a new key into a hash map and the hash function returns the same bucket as an existing key, what will happen and how does the map handle it?
How would you implement a simple hash table that uses chaining to resolve collisions?
We saw a spike in lookup latency for our session cache and the logs show many keys ending up in the same bucket. How would you investigate and fix a possible hash‑collision issue?
When choosing between open addressing and separate chaining for a feature that stores up to 10 k items, what trade‑offs do you consider regarding collisions?
Our distributed key‑value store uses consistent hashing, but a poor hash function is causing many keys to map to the same node. What impact does that have on load balancing and how would you redesign the hashing strategy?
Design a collision‑resilient hashing layer for a high‑throughput logging system that must keep average insert time O(1) even under adversarial inputs.
We are migrating a legacy monolith that uses a custom hash for sharding data across multiple databases, and the current hash creates hot shards due to collisions. How would you lead a cross‑team redesign to improve distribution while minimizing disruption?
At a platform level, how would you evaluate and select a hash algorithm for a global CDN cache handling billions of requests per day, considering collision resistance, performance, and future scalability?